The structural organization of early computer systems was quite simple. A single central processing unit (CPU) was indisputably the brains and the boss of the system. The CPU had exclusive control of all storage, since there was no other component of the system with which to share the storage.
As computer systems became advanced, more processing power was required to perform increasingly complex functions. As an alternative to designing an increasingly powerful CPU to deliver more processing power, computer systems began to share the workload between two or more processors. These computer systems were called multiprocessor systems, or distributed systems.
A major problem with multiprocessing systems is keeping each CPU autonomous from the other CPUs in the system so that they don't destroy each other's storage space as they work on their particular task. In the past, data integrity was obtained by convention and trust among the processors. One method of achieving this autonomy is to give each CPU its own set of resources, including direct access storage. Unfortunately, this duplication of resources is costly and inefficient. Substantial savings can occur if all CPUs could share the system's direct access storage.
Direct access storage can be shared in a multiprocessing system if there is a single storage server responsible for all of the shared storage. Each CPU of the multiprocessing system must go through this storage server to access data in the shared storage. Although storage servers of the past have been able to prevent two processors from accessing the same data at the same time, they lacked the capability to solve a myriad of other data integrity problems that makes truly shared storage a risky proposition.
Another approach to shared storage in a multiprocessing system is physical partitioning of the storage space. In this approach, the storage space is divided arbitrarily among processors in the multiprocessing system for the exclusive use of each processor or set of processors. While this technique solves most data integrity problems, data is not truly available to be shared under this approach; the net effect is again a duplication of resources for each processor. In addition, partitioning on physical boundaries can be inefficient and very wasteful of space. cl SUMMARY OF THE INVENTION
It is a principal object of the invention to provide a multiprocessing system where storage is truly shared among the processors efficiently and without data integrity concerns.
It is another object of the invention to allocate shared storage space dynamically based on the specific needs of each processor.
These and other objects are accomplished by the multiprocessing system with enhanced shared storage disclosed herein.
One processor of a multiprocessor or distributed system is designated as the owner of the shared storage. The remaining processors of the multiprocessor system are designated as requestor processors. The shared storage, typically several disk drive units, are connected to a storage controller. The storage controller is connected to all of the processors via a communications bus.
The shared storage is dynamically segmented into containers of storage space. A container can vary in size and even can be split up among more than one disk drive unit. A container located on one disk drive unit can also be duplicated, or mirrored, on a different disk drive unit. The owner processor maintains a container map in its dedicated non-volatile storage. The container map contains fields that keep track of the physical location of a container, a use count, a key, and container attributes.
When a requestor processor wants to create a container of storage, it sends a "Create Container" request to the owner processor over a request path of the communications bus. The Create Container request may contain the size of the container requested and other optional attributes.
The owner processor places a container entry in the container map, and physically creates a container of the shared storage for the requestor processor.
When a requestor processor wants to use a container of storage, it sends an "Allocate Container" request to the owner processor over a request path of the communications bus. The owner processor reads the entry corresponding to the requested container in the container map. If the use count stored in the container map entry is zero, indicating that this is the first request to allocate a container, the owner processor increments the use count to one and inserts a copy of this container map entry in the container table located in the storage controller. This insert operation is sent too the storage controller over the control path of the communication bus. In response to this insert operation, the storage controller randomly generates a unique key for this container and sends this key to the owner processor. The owner processor places this key in the container map entry corresponding to this container. The owner processor then sends the key to the requestor processor over the request path.
When the requestor processor needs to use the container, it sends the key along with an "Open Container" command to the storage controller over a command path of the communications bus. If this key is the same as a key in the container table, access to the container of data is granted to the requestor processor by the storage controller.
When the requesting processor no longer wishes to have the container of data opened for its use, it sends a "Close Container" request to the storage controller over the command path. A requestor processor may open and close a container several times using the key received from the owner processor in response to the Allocate Container request.
If an Allocate Container request is received by the owner processor over the request path when the use count stored in the container map entry indicates that the container has already been allocated, the use count is incremented and the key to the container is sent directly to the requestor processor. The owner processor does not need to insert a copy of the container map entry into the controller's container table, since this was done on the first Allocate Container request.
When a requestor processor decides that it no longer wishes to have a container of data allocated to it, it sends a "Deallocate Container" request to the owner processor over the request path. The owner processor checks to see if this is last requestor processor to have allocated this container by looking to see if the use count is one. If so, the use count is decremented to zero and the owner processor removes the entry in the container table located in the storage controller corresponding to this container. This "remove" operation is performed over the control path of the communications bus. If the use count is greater than one, indicating that this is not the last requestor processor to have allocated this container, the use count is decremented but the remove operation is not performed.
When the requestor processor that created a container decides that it now wants the container destroyed, it sends a "Destroy Container" request to the owner processor over the request path. After checking to make sure that the use count is zero, indicating that no processor is currently using the container, the owner processor erases the entry from the container map and optionally erases the data in the container itself, thereby destroying the container.